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Abstract 

Most existing approaches towards modeling design 
methodologies concentrate on modeling of design flows 
and design tools. Only a few of them consider ike 
relationships between design methodology and design 
object modeling. Our approach towards modeling the 
heterogeneous aspects of design environments is based 
on a paradigm of separation and integration yiel- 
ding an adequatCf well structured , non-redundant, and 
integrated design model for generic design environ- 
ments. The design model consists of five partial mo- 
dels; (1) design flow model, (2) design tool model, 
(3) design structure model, (4) design object model, 
and (5) design subject model The design structure 
model IS introduced for modeling on a higher level 
of abstraction exaclty those aspects of design objects 
which are necessary for design methodology manage- 
ment The applied concept is called design object 
abstraction, 

1 Introduction 

Computer Systems for supporting engineers in desi- 
gning complex technical objects are topically of great 
interest in design automation community. (Remark: 
In this paper, we chose an example from the field of 
electronics and VLSI design, but we suggest that the 
idea standing behind has a rather general nature and 
would additionally be valuable in other fields of design 
automation, e.g. in the area of mecheinical enginee- 
ring). 

The term CAD framework is commonly used to 
address a system or a system architecture that promise 
to be a suitable, i.e. extensible, adaptable, as well as 
homogeneous environment dealing with design proces- 
ses, tools, and objects. CAD frameworks commonly 
provide the following basic services (cf. [HNSB90]): 
data management, data representation (including ver- 
sioning), user interface, design methodology manage- 
ment, and some low level services (e.g. physical data 
management, process management, etc.). 

Design Methodology Management is cleissi- 
fied as a meta service, because it is a rather abstract 
service supervising the other services. But, it is not 

ior only partially) considered in most of today's CAD 
ramework development approaches. Recently, CFIs 
Design Methodology Management Technical Subcom- 
mittee (DMM-TSC) presented a perspective towards 
Design Methodology Management (cf. [FKKP90]). A 
sequence of hierarchically structured tasks spanning 



all design phases of the whole product life cycle. A 
more abstract point of view, the CFI's DMM-TSC's 
perspective focuses on issues of the design flow. That 
is, it addresses the description and the execution of 
design tools. 

Hence, tool information are required which are 
relevant for design methodology management. The 
applied concept is called tool abstraction. That 
means, it is abstracted as much as possible from the 
individual properties of design tools resulting in a ge- 
neric tool description which, in turn, may be parame- 
terized. Thus, design tools can be characterized by 
sets of parameters. Having made known these tool 
parameters to a particular framework, this can suc- 
cessfully invoke design tools* execution (cf. [TAS90]). 
Beside such abstract tool information, design metho- 
dology management requires some information about 
design objects. For instance, it is necessary to know, 
whether the execution of a design tool (in order to 
perform a particular design task) generates a new ver- 
sion of a design object or an alternative. Further- 
more, hierarchy information about the design objects 
are required for controlling the design flow and execu- 
ting design tools. Today, this information is usually 
included in product models, e.g. EDIF (cf. e.g. 
[EDIF871], STEP (cf. e.g. [STEP88]), VHDL (cf. 
e.g. [VHDL85]), etc. Product models describe design 
data in a granularity and on an abstraction level sui- 
table for design tools. But, for design methodology 
management, a more coarse granularity and a higher 
level of abstraction is necessary. Therefore, a concept 
of design data abstraction is required that may be 
compared with the idea of tool abstraction. 

To gain a high degree of flexibilty and a wide range 
of applications for CAD frameworks, interchangeabi- 
lity of tools, products models, and methodologies must 
be assured similiary. Therefore, an explicit description 
in an appropriate granularity and on an appropriate 
abstraction level of all these components is absolutely 
necessary. 

We propose a modeling approach that considers all 
the different and heterogeneous aspects of design en- 
vironments throughout. Our approach is based on the 
paradigm of separation and integration, which is 
well known in the database community where it is 
applied to get centralized information structures that 
show a high degree of orthogonality. Exploiting this 
concept for modeling design environment yields an 
adequate, well structured, non-redundamt, and inte- 



452 



grated design model. The proposed design model is 
structured in five partial models: (1) design flow mo- 
del, (2) design tool model, (3) design structure model, 
(4) aesign object model, and (5) design subject mo- 
del. The design structure model is introduced for 
modeling exactly those aspects of design objects which 
are relevant for design methodology management. The 
benefits of the proposed approach aie, that it allows 
us to make explicit the prevailing relationships among 
design tools, aesign flows, and structure of design ob- 
jects and to describe design methodologies from an 
rather integrative point of view. 

In section 2 the term design environment as it is 
used in this paper and the role of CAD frameworks are 
addressed. In 2 the different classes of information for 
representing design environments are identified. The 
remainder of this section focus on design methodology 
management. In section 3 the proposed approach is 
compared with other design methodolgy management 
modeling approaches. Finally, section 4 summerizes 
the main ideas and sketch out our future plans. 

2 Design Model 

In our view, a design environment consists of a 
design system and a CAD framework; cf. figure 1. 
A design system (CAD system) consists of design 
tools ^.g. fioorplanner, router) and design data. 
The process within a design system is called design 
process ^. The architecture of design environments 
shown in figure 1 represents the design centered ap- 
proach, cf. e.g. [HNSB90]. That means, all design 
tools are controlled by a central agency. 

Modeling and formalizing all relevant issues of real 
design environments marks the first and the most im- 
portant step towards a system integrated support of 
design processes. An overall design model forms the 
basis of a CAD framework. Only the explicit descrip- 
tion and management of all relevant aspects of design 
environments, design processes can be performed com- 
pletely in a computer aided way by designers* interac- 
tion with design tools and CAD frameworks, respecti- 
vely. 

First of all, a clear semantics of the terms model and 
modeling is given. For instance, the terms system mo- 
del, data models and product mode! are used with dif- 
ferent semantics. A system model describes the beha- 
viour of a system V A data model provides description 
languages for modeling database schemes. A product 
model is a prototype or schema of all data, which are 
relevant for designing a product of a certain product 
class. 

In this paper, the term model is used in the latter 
sense. In figure 2, the relationships among data, mo- 
dels, and modeUng languages are explained. The data 
describe a specific object, e.g. a product or a system. 
Abstracting models are type or schema descripti- 
ons of the data on a higher level of abstraction. On 
the most abstract level, modeling languages pro- 
vide tools for specifying models. Modeling languages 
can be also called application model budding set, 

^The applied term sjfsicm stems from system dynamics 
theory for inform&tion processing (cf. e.g. [We89]. 



which can be used for building models or schemas, 
respectively. 

2.1 Information Classes in Design Envi- 
ronments and Their Modeling 

Refering to figure 1, within design environments the 
following relevant components can be identified: 

• Design data of design objects (e.g. VLSI cells) 

• Design tools (e.g. floorplanners, simulators) 

• Design flow control 

• Design subjects (e.g. designers, teams, projects) 

Design data 

describe design objects (e.g. products, systems, 
etc.), which are the key elements within each 
design environment. Design data describe the 
design objects on different design levels of ab- 
straction (i.e. levels of design hierarchies) and 
in different design domains . 
Models for describing models of design data are 
called design object models. Design object 
models contain all aspects of a designed pro- 
duct, that are relevant for the design process 
independent product documentation (functiona- 
lity, physical properties, geometry, etc.). Since 
design data depend heavily on the considered 
industry, the specificatiopn of an overall design 
object model is not possible. Furthermore, the 
specification of an industry-wide design object 
model causes severe problems, because of spe- 
cific properties of the related design processes 
and companies, respectively. In some industries, 
there are standardization efforts for design ob- 

i'ect models on the way, e.g. EDIF (cf. e.g, 
EDIF87D, STEP (cf. e.g. [STEP88]), VHDL 
cf e.g. tvHDL85]), etc. 

Modeling languages for describing design ob- 
ject mo deb are traditional database models 
extended by the well known abstraction con- 
cepts, i.e. classification, aggregation, generali- 
zation, and association. 

Design tools 

(e.g. floorplanners, simulators, etc.) constitute 
the means used by the engineers to progress the 
design. Design tools are the active components 
within design environments. For instance, for 
each design tool, the performed design tasks, the 
required input data, the expected ouput data, 
etc. must be described. Furthermore conditions, 
environment variables (e.g. parameters, options, 
runtime environment, log protocols, etc.) used 
for the design tool executions must be descri- 
bed. 

All information about design tools are model- 
led in the design tool model. The CAD Fra- 
mework Initiative (CFI) tries to standardize a 
design tool model as Tool Encapsulation Spe- 
cification (cf [CFI91]). Here, it is abstrac- 
ted from the specific properties of design tools 
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yieMing exaclty those information, which are re- 
levant for CAD environments. This concept is 
called design tool abstraction. 

Desi^ flow control 

IS the major component of frameworks. A design 
flow consists of a sequence of design activities 
i.e. design tool applications. Since, parallel ap- 
plications are also possible, design flows can be 
seen as suitable acyclic graphs, where the nodes 
represent activities, and the arcs represent the 
dependencies between activities. Thus, desigp 
flows describe the way how a design objecs is 
designed by the design subjects using the design 
tools. The terms design flow and design process 
are used synonymeously. 

Design flow models specify the possible design 
flows for a certain design methodology. Thus, 
design flow models allow one to determine cor- 
rect design flows. Correctness is defined from a 
methodology point of view. 
Modeling languages for design flow models 
are often petri net like formalisms, where firing 
of transistions corresponds to activating design 
tools, and tokens are associated to design ob- 
jects or, in general, to design situations. 
We believe, modeling design flows appropriately 
requures additionally a rule based description ca- 
pability for specifying a methodology based con- 
trol flow. For instance, in several design situati- 
ons it must be possible to formulate quantified 
preconditions for the continuation of the design 
flow (cf. [BD86])- 

Design subjects 

arc involved in design processes, e.g. (1) 
designers, as users of design tools, (2) tool m- 
tegrators, who integrate new tools mto frame- 
works, (3) developper of design methodologies, 
who plan design processes, (4) project managers, 
who manage design projects (cf. [FKKP90]). 
These different user classes need different parts 
of the other information classes (e.g. design ob- 
ject data, design tool data). 
Design subject models describe the different 
user types in design environments and their ac- 
cess and authorization rights. Design subject 
models are well known in database technologies. 

2.2 Design Structure Model 

As discussed in the previous sections, the design 
flow control needs information about the design tools 
as well as about the design objects. Whereas, the 
instances of the design tool model represent suitable 
information about design tools for design flow control, 
the data of design object models do not. 
First, the data of design object models are too detai- 
led, i.e. the granularity of design data used by design 
tools is too small for design flow control. For instance, 
the application of a certain router rather depends on 
the existence of a whole netlist, than on the existence 
of certain pins. 

Secondly, some important information are missing, 



which are relevant for design flow control, e.g. data 
about versicms and alternatives ofdesign objects. For 
the design tool itself, this information is not relevant, 
because it always gets exactly one schematic as input 
data. 

Summarizing, a suitable model representing these 
kmds of information is necessary. This model must 
represent the following information required by the 
design flow control: 

• Information about the existence of design data 
in a large granularity. The design flow control 
must be informed about the status of the design 
process for activating the correct design tools. 

• Information about the design hierarchy. 

• Information about the history of design data, 
e.g. which design tools were activated in which 
sequence, and which parameter values were 
used. 

• Information about versions, alternatives, etc. 
(i.e. version model) 

• Information about the design structure hierar- 
chy of each design process 

• Information about configurations among diffe- 
rent design structure hierarchy levels (i.e. confi- 
guration model) 

The related model is called design structure mo- 
del, because it models information about the struc- 
ture of design processes. The design structure model 
abstracts form the design data, such that only the re- 
levant aspects for controlling and monitoring design 
processes by CAD frameworks are represented. 
Whereas design object models are tool specific, the 
design structure model is tool independent. Hence, 
the design structure model can be combined with va^ 
rious design object models. 

More important, information, which is modeUed 
today in several design object models, but not used 
by the design tools, need not to be modelled any more 
by the design object models (e.g. design hierarchy, 
version model, configuration model). Thus, data in- 
consistency problems yielding from data redundancies 
are avoided. 

The abstraction concept applied for building the 
design structure model can be compared with the tool 
abstraction concept applied for building design tool 
models. Hence, it is called object abstraction con- 
cept. Therefore, the entities of an instance of the 
design structure model are called meta objects. 

Today, there are strong standardization efforts for 
product models on the way (e.g. EDIF (cf. e.g. 
[EDIFS?]). STEP (cf. e.g. [STEP88]), VHDL (cf. e.g. 
[VHDLSoJ), etc.). But, these product models are de- 
veloped and standardized without differentiating bet- 
ween the issues concerning design object models and 
the issues related to design structure models. Thus, 
it is difficult to relate the difl*eTent product models to 
a common design structure model, which is used by 
several frameworks. Furthermore, there are no stan- 
dardization efforts for design structure models. 
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2.3 Modeling Design Methodologies 
Since the design methodology forms the most im- 

Eortant issue in modeling design environments, it must 
e explicitly described in the design model. Design 
methodology is often reduced to the aspect of design 
flow, because design flows give a criterion to distin- 
guish design methodologies. But in our opinion, 
design methodology is strongly influenced additionally 
by the available design tools, and by several particular 
aspects of the design objects, i.e* the design structure. 

In flgure 3 all Ave partial models and their relation- 
ships and interfaces are shown. A possible reflnement 
of each partial model is illustrated by a simple exam- 
ple. 

Relationships of the design object model 

The relationship between the design object mo- 
del and the design structure model was al- 
ready discussed in the previous section. The re- 
lationship is determined by the fact that each 
object model represents a particular aspect of a 
design object. As shown in figure 3, the relation- 
ships between the design object model and the 
design structure model are called views. Views 
are the large granulates of design data in the 
design object model, which are related to the ele- 
ments in the design structure model. Examples 
for views neilisi^ schcmaiic^ etc. Views form the 
smallest access granularity of design objects used 
to describe a design methodology with respect to 
the design structure model and the design tool 
model. Of course, this granularity is not defined 
in general, but it has to be adapted according to 
the used design tools. 

Summarizing, the granularity of views is a trade- 
off between supplying too much and unnecessary 
data and complicating the design management 
by increasing needlessly the number of views. 

Relationships of the design tool model 

The design data used and generated by the 
design tools should be modelled by the design 
tool model in the same granularity as by the 
design structure model. This granularity re- 
sults from the data requests of the design tools. 
The granularity should be fine enough, such that 
the data exchange among the design tools can 
be described. But, the granularity must be as 
coarse as possible. Otherwise, design manage- 
ment is too complicated. 

Summarizing, with respect to the design object 
model, design data are modelled by the design 
tool model as views. Thus, the relationship bet- 
ween the design tool model and the design ob- 
ject model are views. But, the relationship 
between the design tool model and the design 
structure model are the entities of the design 
structure model itself, i.e. the meta objects, 
like versions and variants. For instance, this ne- 
cessary, when design tools should generate ver- 
sions or variants of a schematic. Since the in- 
formation about versions and variants should be 
only modelled in the design structure model, the 



information given by the design tool model is 
not sufficient. Furthermore, information about 
structure hierarchies should only be also model- 
led by the design structure model. Thus, for 
accessing design data on different hierarchy le- 
vels by a design tool, the related objects in the 
design structure model must be used. 

Relationships of the design flow model 

The design flow must point to the design tools 
as active components of design processes as well 
as to the design data as passive components of 
design process. For instance, in a petri net ba- 
sed flow description, the tokens are instances of 
these entities, i.e. the tokens are an abstraction 
of the design data as described by the design 
structure model, and the transitions represent 
design tool executions. Again, the granularity 
of design data axe views, i.e. the relationship to 
the design object model are views. The rela- 
tionship between the design flow model and the 
design structure model are the entities of the 
design structure model itself, i.e. the meta ob- 
jects. This is necessary for modeling design flows 
dealing with variants, versions, hierarchies, etc. 

Relationships of the design subject model 

The design subject model needs the sarne gra- 
nularity of design data as the other partial mo- 
dels. Thus, the relationship of the design sub- 
ject model and design object model are views. 
Furthermore, for coupling user authorizations to 
versions, hierarchies, etc. the relationship bet- 
ween the design subject model and the design 
structure model are the meta objects of the 
design structure model, again. 

Summarizing, the discussion of the inter relationships 
of the various partial models shows the central role of 
the design structure model. Following this approach, 
modeling of complex flows and methodologies is pos- 
sible. 

Furthermore, the strong relationships among these 
models require an integration of the partial models 
yielding an integrated design model. 

The key characteristics of the given approach are 
the five widely orthogonal dimensions for describing 
design environments as well as the clarity and explicity 
of the interfaces between these dimensions. Thus, the 
interchange of partial models is easy. For example, 
a modification of the hierarchy representation or of 
the versioning concept must not cause a change of the 
flow model. Only the representation within the design 
structure model have to be adapted. 

2.4 Design Methodology Specification 

In our approach, the design tool model, design flow 
model, and design structure model specify the design 
methodology. The design flow model is necessary, 
because a a design methodology is implemented by a 
sequence of design tool executions. The design tools 
are the aictive components of design processes, i.e. 
the operators. The operators must be known to 
the design methodology, i.e. required input data and 
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expected output data, design tool functionality, etc. 
Hence, the design tool model is essential for describing 
the design methodology. But, the design tool model 
should be independent of a specific design methodo- 
logy. That means, the description of the design tools 
should not depend on the chosen design methodolgy. 

Because of its central role, the design structure 
model is also necessary for describing design metho- 
dologies. For instance, a hierachical top down or bot- 
tom up design can be only described by the design 
structure model. The design structure model shomd 
be as generic as possible, such that as much as possible 
design methodologies can be described. 

Following our approach, design methodologies can be 
described explicitly using these the different partial 
models. The benefits of an explicit description of the 
design methodology are: 

• Complex design processes can be managed and 
controlled, i.e. they can be planned, traced, re- 
viewed, and recovered, respectively. 

• Design engineers can be supported by special 
tools for project management, e.g. for selecting 
the most appropriate design tool from the pool 
of available design tools. 

• The entire design process can be optimized in 
global way. 

The approach can be compared with describing al- 
gorithms within a common programming environ- 
ment. The most programming languages like PA- 
SCAL, C, or M0DULA2 require: (1) the specification 
of the data structures, (2) the specification of proce- 
dural primitives, and (3) the procedural specification 
of the control flow. 

Considering this analogy, the definition of a design 
methodology can be specified by the following steps: 

1. The design structure (cf specification of data 
structures) is specified in order to determine the 
information primitives the methodology is based 
on. 

2. The design tools are introduced (cf. specification 
of procedural primitives). Thus, the operational 
primitives used by the design methodology are 
defined. 

3. The design flow is defined (cf. specification of 
the control flow). The design flow represents the 
dynamic and strategic aspects of the design me- 
thodology. 

Summarizing, if these aspects of design objects are 
not described in the design structure model, they must 
be modeled either in the design flow model or in the 
design object model. Both cases yield to an unnatural 
and redundant modeling. The flow model and object 
model are semantically overloaded. Moreover, redun- 
dant modeling leads to consistency problems. Hence, 
the structure model allows a non redundant and uni- 
form modeling of design environments in a singe design 
model. This is a major basis of an efficient Design Me- 
thodology Management. 



3 Comparision of Related Work 

In the following, we would like to discuss the ad- 
vantages of the proposed design model in more detail. 
Therefore, we compare our modehng approach with 
the concepts given by the references. In fBKLHWOO] 
design flows of the VENUS system are described by 
extended predicate transistion petri nets. The Hierar- 
chical Specification contains tokens with the hierarchy 
relationship of the tokens at the other places, which 
represent design data of the domsun siruc/ure (e.g. net- 
lists). This kind of flow model does not only describe 
dynamic aspects, but deals also with static aspects 
like hierarchies. Thus, the hierarchy information must 
also be represented in the database of the underlying 
HILDA franiework (cf. [HII87]). Obviously, the mana- 
gement of this redundant information is very disadvan- 
tageous from a data modeling point of view. The con- 
sistency of multiple representations of the same fact 
has to be controlled by the CAD framework. For in- 
stance, even a simple delete operation on the database 
requires the deletion of all corresponding hierarchy to- 
kens without disturbing the flow execution. Hence, 
the delete operation consists of several suboperations, 
and the delete operation must be handled as a tran- 
saction responding to the ACID principle (cf. [Gr81], 
[HR83]). This means, if this transaction is aborted for 
some reason, the state before starting the delete ope- 
ration must be recovered. Hence, all removed tokens 
must be restored without getting in conflict with the 
pending transitions and the firing rule of the petri net. 

Considering that the hierarchy representation 
within HILDA meets only simple cases (in reedity the 
design objects have versions, alternatives, and configu- 
rations), we can imaging that this flow model becomes 
very compHcated and the control of correct execution 
nearly seems to be impossible. Summarizing, this kind 
of flow model is inadequate for modehng hierarchies, 
versioning, and configurations. 
The conclusion of all these problems shows the de- 
mand for clearly separating the design flow description 
and the design structure in two related partial models 
to avoid redundancy. 

4 Conclusion 

To meet the needs of design tool developers as well 
as of design methodology management, a clear sepa- 
ration of the design data model into design structure 
model and design object model is necessary. These 
two models decribe the design data on different ab- 
straction levels and granularities as used by the design 
tool developer and design methodology management, 
repectively. This seperation and the integrated mo- 
delling of the relationships of the design flow model 
and design tool model to the design structure model 
enables the interchfingeability of design tools, design 
methodolgies, and product models (i.e. one design 
structure model for all design object models) within 
CAD frameworks. 

The design structure model restricts and organizes 
the set of possible design methodologies. For instance, 
it makes no sense to use design alternatives and librae 
ries, if alternatives or instances of design objects are 
not represented efficiently by the design structure mo- 
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del. Thus, one of the first goals of the developers of 
a design system (if not the major one) should be the 
development of a general, not less expressive design 
structure model that supports different design styles 
and all kind of design objects. Because of even the best 
model cannot meet all future needs, this model should 
be easily extensible. Hence, the design structure mo- 
del should be seperated from the other partial models 
of the design model. Thus, changes of the design struc- 
ture model require no or only minimal changes of the 
design object model as well as the design tool model. 

Summarizing, only an adequate abstraction both 
from the CAD tools (design tool model) and the design 
objetcs (design structure model) integrated in single 
design model with clear and simple interfaces among 
the partial models makes the design methodology ap- 
propriately manageable. 

The ideas addressed in this paper have already in- 
fluenced the design and will determine the ongoing 
implementation of an CAD framework prototype sup- 
porting VLSI chip design. Currently, we are working 
on getting more expieriences in carrying the modeling 
concepts into and to exploit them in the area of me- 
chanical design environments. 
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Figure 1: Design Environment for a Design Centered 
Approach 
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Figure 2: Modeling Levels 
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Figure 3: Design Model 



